src/utils/sqrt.rs (1)

Line range hint 22-49: Add test coverage for negative input case.

While the test coverage is comprehensive for valid inputs, there's no test verifying the error handling for negative inputs. Consider adding a test like this:

#[test]
fn test_sqrt_negative() {
    let negative = BigInt::from(-1);
    match sqrt(&negative) {
        Err(Error::Invalid(msg)) => assert_eq!(msg, "NEGATIVE"),
        _ => panic!("Expected Error::Invalid(\"NEGATIVE\") for negative input"),
    }
}

src/error.rs (3)

12-14: Consider enhancing the documentation with an example.

The rename to UintOverflow and the specific mention of U256::MAX in the error message are good improvements.

Consider adding an example to the documentation to show when this error might occur:

-/// Triggers when it tries to exceed [`alloy_primitives::U256::MAX`].
+/// Triggers when a numeric operation would exceed [`alloy_primitives::U256::MAX`].
+///
+/// # Example
+/// This error occurs in operations like currency amount multiplication where
+/// the result would exceed the maximum allowed value.

---

20-22: Consider adding validation and documentation for Invalid variant.

While the addition of a &'static str parameter allows for more specific error messages, consider:

1. Adding documentation about expected format/content of error messages
2. Creating constants for common error messages to ensure consistency

/// Common error messages for the Invalid variant
pub mod error_messages {
    pub const SIGNIFICANT_DIGITS: &str = "SIGNIFICANT_DIGITS";
    // Add other common error messages here
}

---

43-55: Consider adding negative test cases.

While the current tests verify the error messages correctly, consider adding tests for:

1. Invalid error messages (empty strings, very long messages)
2. Different chain ID combinations
3. Edge cases for currency mismatches

#[test]
fn test_chain_id_mismatch_combinations() {
    let cases = [(0, 1), (u64::MAX, 0), (u64::MAX, u64::MAX - 1)];
    for (id1, id2) in cases {
        let error = Error::ChainIdMismatch(id1, id2);
        assert_eq!(error.to_string(), format!("chain IDs do not match: {} and {}", id1, id2));
    }
}

src/utils/sorted_insert.rs (3)

11-16: Consider the implications of switching from Results to panics.

The change from Result<Option<T>, Error> to Option<T> with assertions represents a significant shift in error handling strategy. While this simplifies the API, it also means that invalid inputs will now cause panics instead of returnable errors.

This is a breaking change that:

• Makes the function more ergonomic for valid inputs
• Treats max_size validation as a programming error rather than a runtime error
• May require updates to error handling in consuming code

Consider whether these conditions truly represent programming errors (that should panic) rather than runtime errors (that should return Result). If these could be runtime conditions, consider keeping the Result return type for more graceful error handling.

---

56-59: Enhance the array length validation test.

While the test correctly verifies the panic message, it could be more thorough by testing with different array and max sizes.

Consider adding more test cases:

#[test]
#[should_panic(expected = "array length cannot exceed max_size")]
fn test_length_greater_than_max_size_variants() {
    // Test with different array sizes exceeding max_size
    let mut arr1 = vec![1, 2, 3];
    sorted_insert(&mut arr1, 1, 2, cmp);

    let mut arr2 = vec![1, 2, 3, 4, 5];
    sorted_insert(&mut arr2, 1, 3, cmp);
}

---

Line range hint 3-5: Update documentation to reflect panic conditions.

The function documentation should be updated to explicitly mention the panic conditions for invalid inputs.

Consider updating the documentation:

 /// Given an array of items sorted by `comparator`, insert an item into its sort index and constrain
 /// the size to `maxSize` by removing the last item
+///
+/// # Panics
+/// 
+/// This function will panic if:
+/// - `max_size` is zero
+/// - The length of `items` exceeds `max_size`

src/entities/fractions/currency_amount.rs (1)

126-126: Consider enhancing the error message with more context.

While the change from NotEqual to Invalid("DECIMALS") is an improvement, the error message could be more specific about why the decimals are invalid.

Consider using a more descriptive error message that includes the actual and maximum allowed decimal places:

-return Err(Error::Invalid("DECIMALS"));
+return Err(Error::Invalid(&format!(
+    "Requested {decimal_places} decimals exceeds currency's {max} decimals",
+    max = self.currency.decimals()
+)));

Configuration used: CodeRabbit UI
Review profile: CHILL

#!/bin/bash
# Description: Check for potential breaking changes in error handling

# Test 1: Look for thiserror derive macro usage
rg -l '#\[derive\(.*Error.*\)\]'

# Test 2: Check for custom error implementations
rg -A 3 'impl.*Error.*for'

# Test 3: Look for error type definitions
ast-grep --pattern 'pub enum $name {
  $$$
}'

#!/bin/bash
# Get the content of error.rs to analyze the error types and their implementations
cat src/error.rs

# Also check for any thiserror macro usage patterns
rg -p '#\[derive\(.*Error.*\)\]' src/error.rs -A 5

#!/bin/bash
# Description: Check for consistent error message patterns in Invalid errors
# Expected: All Invalid errors should use descriptive static strings

# Search for Error::Invalid usage
rg "Error::Invalid\(" -A 1